I'd like to view this as proof of concept and base for discussion.
Fixes #354.
Builds upon #418.

Basically this PR adds support for HUSL (http://www.husl-colors.org/) perceptual colours. I have chosen that over Lch or Lab, because it doesn't allow the definition of colours that cannot be represented in the RGB colour space. This and its similarity to HSL make its use convenient and avoids trial-and-error colour definitions (see #354 (comment) for an expanded explanation why I think this is beneficial).

The implementation has the following characteristics:

• the colour object knows if it is a perceptual colour or not
• internally colours are no longer represented in rgb but in hsl (or husl) values
• colour functions like lighten, darken operate on the respective colour space (internally they only manipulate hsl or husl values)
• there are lightenp, darkenp, ... functions to force a colour into perceptual colour space
• hue, saturation, ... always return the value of the (converted) non-perceptual colour
• huep, saturationp, ... always return the value of the (converted) perceptual colour
• the mix function operates on perceptual colours if there is at least one perceptual colour in its parameters
• chained colour functions operate on the HSL or HUSL space as long as possible, the conversion to rgb or rgba is done at the end

The similarity of hsl and husl in terms of values keeps the representation simple. The perceptual colour space is kind of sticky. Once you are in it is difficult to get out again, but I thought this would be no problem.

I have extended test coverage, which @pnorman started in #418, further to all new colour functions.